Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaDevices.produceCropTarget -> CropTarget.fromElement #50

Merged
merged 11 commits into from
Jun 2, 2022

Conversation

eladalon1983
Copy link
Member

@eladalon1983 eladalon1983 commented May 20, 2022

Change the point of exposure of token-minting from:
MediaDevices.produceCropTarget()
To:
CropTarget.fromElement()

Everything else is kept as-is, to be debated and improved in subsequent PRs.


Preview | Diff

Change the point of exposure of token-minting from:
  MediaDevices.produceCropTarget()
To:
  CropTarget.fromElement()
@eladalon1983
Copy link
Member Author

@jan-ivar has requested that Chrome should hold off on shipping Region Capture so that we may keep discussing. Both @jan-ivar and @youennf have been extremely responsive in interacting with the discussion on the various issues of this API in the last few weeks. I would be gratified if you could also be similarly responsive in reviewing PRs that solidify the consensus we have worked so hard to achieve.

CC @dontcallmedom

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
Copy link
Contributor

@beaufortfrancois beaufortfrancois left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the sample code at https://w3c.github.io/mediacapture-region/#sample-code should be using CropTarget.fromElement() instead of mediaDevices.produceCropTarget().

The README.md file would also benefit from these changes for consistency

@@ -151,7 +151,7 @@ <h3><dfn>CropTarget</dfn> Definition</h3>
<pre class="idl">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text above should be edited as well. It currently says:

          CropTarget is an intentionally empty, opaque identifier that exposes nothing. Its sole
          purpose is to be handed to {{BrowserCaptureMediaStreamTrack/cropTo}} as input.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That much seems still correct, given that the only method is static. We'd probably not have created this CropTarget as an exposure point for fromElement if we went, say, with the UUID-based solution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "exposes nothing" part was what triggered me as CropTarget.fromElement() is something to me.
Your call though ;)

Copy link
Member Author

@eladalon1983 eladalon1983 May 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could remove "exposes nothing". Would that make things clear enough, or would "intentionally empty" be confusing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing exposes nothing would work for me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To increase visibility of this change to other reviewers: I've also removed "sole".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

index.html Outdated Show resolved Hide resolved
@eladalon1983
Copy link
Member Author

I believe the sample code at https://w3c.github.io/mediacapture-region/#sample-code should be using CropTarget.fromElement() instead of mediaDevices.produceCropTarget().

Thanks for catching!
Done.

The README.md file would also benefit from these changes for consistency

I'll send a separate PR once this one is merged. I think it would require a bit more prose to be updated, so it might take a few more iterations, whereas here I hope we're mostly done.

@@ -151,7 +151,7 @@ <h3><dfn>CropTarget</dfn> Definition</h3>
<pre class="idl">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

index.html Show resolved Hide resolved
</dt>
<dd>
<p>
Calling {{CropTarget/fromElement}} with an {{Element}} of a supported type associates
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"supported type" here carries no definition, and the algorithm specifies no type validation, which means it is just confusing and should be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is prose was moved unchanged. The status quo of the document has not been altered. Let's have a separate discussion for this.

index.html Show resolved Hide resolved
Calling {{CropTarget/fromElement}} with an {{Element}} of a supported type associates
that {{Element}} with a {{CropTarget}}. This {{CropTarget}} may be used as input to
{{BrowserCaptureMediaStreamTrack/cropTo}}. We define a
<dfn>valid CropTarget</dfn> as one returned by a previous call to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't belong here which I've stated in #29 (comment), but since this is in some ways a code-move, I'll accept a separate PR to remove it, in order to break down changes into smaller PRs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is prose was moved unchanged. The status quo of the document has not been altered. Let's have a separate discussion for this.

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
eladalon1983 and others added 2 commits May 27, 2022 10:38
Co-authored-by: Jan-Ivar Bruaroey <[email protected]>
Co-authored-by: Jan-Ivar Bruaroey <[email protected]>
@youennf
Copy link
Contributor

youennf commented May 27, 2022

I made this API proposal based on the consensus we achieved that all elements would be supported.
Given #51 wants to revisit this, this makes me wonder whether we should pause this PR until we resolve #51.

@eladalon1983
Copy link
Member Author

eladalon1983 commented May 27, 2022

I made this API proposal based on the consensus we achieved that all elements would be supported. Given #51 wants to revisit this, this makes me wonder whether we should pause this PR until we resolve #51.

The current PR would still be an improvement over mediaDevices.produceCropTarget() and we should therefore merge it. Also, please note this message I have posted on #51:

@youennf, you have previously agreed HTMLElement made sense, and #13, we even expanded to Element. You made this suggestion five months ago. The API as a whole has been debated for 1.5 years by now. I do not think this qualifies as "rushed". It is the nature of our jobs that decisions must be made without full certainty. Past a certain point, additional debates are less productive than making a decision, even if that decision could end up proving less than perfectly optimal. (To clarify - I think we're making a good decision in #50.)

Let's press onwards. Many productive issues await us.

@eladalon1983
Copy link
Member Author

@jan-ivar and @youennf, PTAL.

@eladalon1983 eladalon1983 merged commit 0ae2fc3 into w3c:main Jun 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants